Description

Revokes an access token so that it becomes invalid before it expires (see RFC 7009)

Request

To revoke an access token, the client application must send the following request to TRIDENT using TLS

POST /trustedx-authserver/oauth/token/revoke

Content-Type Header

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

Body

Parameter	Usage	Description
`token`	Required	Token to be revoked
`token_type_hint`	Optional	Type of token to be revoked. TRIDENT currently does not take into account this parameter. We recommend not using it or assigning it the value `"access_token"`.

Authentication of the Client Application

Public client applications (installed/native applications) do not need to authenticate to use this operation.

In other cases, the application must authenticate using the HTTP basic authentication scheme. As credentials, the application must specify the identifier and secret assigned to the application during its registration in TRIDENT (the Client identifier and Client secret fields of the Client application), encoded as specified by OAuth 2.0.

Specifically, the application must include an Authorization header with the following structure:

Authorization: Basic {credentials}

Where {credentials} is the result of encoding the client identifier of the application (client_id) and its secret (client_secret) as follows:

base64(url_encode(utf8(client_id)) ':' url_encode(utf8(client_secret)))

The meaning of the above pseudocode is:

Encode client_id first in UTF-8 and then according to the URL character escape rules.
Encode client_secret first in UTF-8 and then according to the URL character escape rules.
Concatenate both using colons (“:”) as the separator.
Encode the resulting string in base64 without line breaks.

The rules for escaping characters in URLs are those defined for the application/x-www-form-urlencoded MIME format in the HTML specification that must be applied to the bytes resulting from encoding the identifier or secret in UTF-8. See the example below

Note

The HTTP basic authentication scheme defined in RFC 2617 does not specify that the credentials must be encoded in UTF-8 and in URL format. The use of these additional encoding rules is part of OAuth 2.0. If a software library or tool that generates the Authorization header as per RFC 2617 is used, keep this in mind, especially when the identifier or secret contains extended symbols or characters.

Example

This example shows a request for revoking a token sent by an application with the "demapp" identifier and the "om+4a_.CE-qüKC mK:3&V" secret. Ellipses and line breaks have been included to facilitate reading.

POST /trustedx-authserver/oauth/token/revoke HTTP/1.1
Host: trustedx.demo.com:443
Authorization: Basic ZGVtb2FwcDpvbSUyQjRhXy5DRS1xJUMzJUJDS0MrbUslM0EzJTI2Vg==
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
 
token=a5f8...6aaf

Before they were included in the Authorization header, the client identifier and secret were encoded in UTF-8 in URL format. Specifically, the value of the header was generated as base64("demoapp:om%2B4a_.CE-q%C3%BCKC+mK%3A3%26V") after the following conversions were applied:

The "+" character was converted to "%2B".
The "ü" character, which is encoded in UTF-8 with two bytes, was converted to "%C3%BC".
The " " (space) was converted to "+" (TRIDENT also accepts encoding it as "%20").
The ":" character was converted to "%3A".
The "&" character was converted to "%26".

The rest of the characters of the identifier and the secret used in this example do not need conversions.

Response

Status-Line

Both if the access token is revoked successfully and if it is not revoked because it is invalid (e.g., because it expired, was already revoked, or was never generated), the HTTP response will contain the following Status-Line (see HTTP Response Status for all the possible cases):

HTTP/1.1 200 OK